Verwandte ThemenBeschrieben wird die Besonderheit der Darstellung einer Datenassoziation im Diagramm im Gegensatz zur dahinter stehenden eigentlichen Verknüpfung. Außerdem wird der automatische Übertrag von Eigenschaften eines datentragenden Elements auf ein zu verbindendes Element beschrieben.
Datenassoziationen dürfen gemäß BPMN-Spezifikation nur datentragende Elemente verbinden und müssen immer eine Aktivität oder ein Ereignis als Besitzer haben. In der Visualisierung verläuft die Kante aber stets zwischen der Besitzeraktivität und – auf der anderen Seite – dem datentragenden Element.
Zieht (Erzeugen oder Umhängen) man eine Kante von einem datentragenden Element zu einem Task/Ereignis, so wird die Kante dem Task/Ereignis zugeordnet und an dem Task/Ereignis wird ein nicht sichtbarer Daten-Input als Ziel der Kante erzeugt. Da das eigentliche Ziel der Kante nicht zu sehen ist, scheint es im Diagramm, als wäre die Datenassoziation direkt mit dem Task/Ereignis verbunden. Der umgekehrte Fall, dass man eine Kante von einem Task/Ereignis zu einem datentragenden Element zieht, läuft analog, nur dass hier ein nicht sichtbarer Daten-Output am Task/Ereignis erzeugt wird.
Zieht (Erzeugen oder Umhängen) man also eine Kante von einem datentragenden Element zu einem Teilprozess, so wird die Kante dem Teilprozess zugeordnet und innerhalb des Teilprozesses wird ein Daten-Input als Ziel der Kante erzeugt, jedoch nicht mit dieser grafisch verbunden. Aus diesem Grund scheint es im Diagramm, als wäre die Datenassoziation direkt mit dem Teilprozess verbunden. Der umgekehrte Fall, dass man eine Kante von einem Teilprozess zu einem datentragenden Element zieht, läuft analog, nur dass hier ein Daten-Output im Teilprozess erzeugt wird.
Um eine Datenassoziation zu erzeugen, zieht man via Karussell zwischen einem datentragenden Element und einer Aktivität/einem Ereignis die Kante. Dabei wird implizit zuerst an der Aktivität/dem Ereignis ein Daten-Input bzw. ein Daten-Output, je nachdem ob die Aktivität/das Ereignis Ziel oder Quelle der Assoziation ist, erzeugt. In Teilprozessen wird dieses Datenelement sichtbar, an Tasks/Ereignissen nicht. Im Modellbrowser kann man das Datenelement als der Aktivität/dem Ereignis zugeordnetes Unterelement immer sehen. Der neue Daten-Input/-Output erhält denselben Namen wie das Datenelement auf der anderen Seite der Assoziation. Gegebenenfalls ist dieser Name jedoch noch so modifiziert, dass er im Namensraum der Aktivität/des Ereignisses eindeutig ist. Zuletzt wird dann die Datenassoziation zwischen den beiden Datenelementen angelegt.
Das Umhängen der Quell- oder Zielseite einer Datenassoziation im Diagramm ist immer nur auf ein Element derselben Elementklasse möglich d.h. entweder zwischen Aktivitäts-/Ereignisknoten oder von einem datentragenden Element auf ein anderes.
Der Wechsel einer Datenassoziationsseite auf eine neue Aktivität/ein neues Ereignis impliziert zunächst einen Besitzerwechsel der Datenassoziation. Außerdem braucht man einen Daten-Input/-Output an der Aktivität/dem Ereignis um die Datenassoziation intern verknüpfen zu können. Um dieses Datenelement zu bekommen, wird zunächst nach einem freien, passenden Daten-Input/-Output an der Zielaktivität/am Zielereignis gesucht. Passend ist das Datenelement, wenn es bzgl. Namen und zugeordneter Begriffsdefinition (BPItemDefinition) und Elementklasse (Daten-Input/-Output) mit dem aktuell verbundenen Datenelement übereinstimmt. Frei ist ein solches Element, wenn es noch mit keiner Datenassoziation verknüpft ist. Wird kein freies und passenden Datenelement gefunden, so muss wie beim Erzeugen ein entsprechendes Element angelegt werden. In diesem Fall gilt es, Eigenschaften des Ausgangselements auf das Neue zu übertragen. Dies betrifft den Namen, die verbundene Begriffsdefinition sowie eventuell zugeordnete Zustände.
Löscht man eine Datenassoziation, so werden außerdem die zugehörigen Daten-Inputs/-Outputs an Tasks und Ereignissen entfernt, falls diese keine sonstigen Verbindungen mehr haben d.h. sie dürfen mit keinen anderen Datenassoziationen verbunden sein oder im Fall von CallActivities (Task mit Task-Typ 'Aufrufaktivität') keine Daten-Inputs/-Outputs des aufgerufenen Elements referenzieren.
Entstehen oder entfallen Datenein-/ausgaben durch oben beschriebene Mechanismen, so kann das in Zusammenhang mit Aufrufaktivitäten und ihren aufgerufenen Elementen zu weiteren Pflegeaktionen führen.
Verwandte Themen
Innovator X Generation 11 R4 - Copyright © 2011-2012 - MID GmbH Nürnberg - DIN EN 9001 zertifiziert - Alle Rechte vorbehalten.